As Virtual Machines (VM) are introduced into Campus and Data Center networks, the number of hosts connected by switching systems at datacenter grows dramatically. The number could be hundreds of thousands or even millions. Traditional three-tier network architecture can no longer meet the requirements at these types of datacenter network because as number of VMs grows, more switches and routers have to be added. Such grown would cause dramatic increase on latency, complexity and cost.
The latest switching systems developed for such types of Data Center networks are designed with a flatten architecture that consist of multiple L2/L3 switching devices (SD). These SDs are linked together directly (e.g., by full-mess or cascade architecture) or through a switching fabric device (SFD) (e.g., a hub-spoke architecture) to form a virtual switch. All these devices are controlled by a central controller. Routing protocols run on the central controller as a single routing entity. All traffic goes through this system as if switching through a single L2/L3 device. In such a switching system, a packet forwarded cross SDs goes through two stages of hardware lookup/forwarding, where one stage is at the ingress SD and another stage is at the egress SD.
With traditional implementations, the size of a Forwarding Information Base Content Addressable Memory (FIB CAM) table and a next-hop table (e.g., an ADJ table) increase as the number of directly connected hosts increase. This is because for every such a host, one FIB entry and one next-hop entry are required assuming there is at least another directly connected host communicates with that host. However, to increase FIB CAM and next-hop table size would significantly increase cost considering the number of switch devices involved in a large switching system. Because customers seek inexpensive, low-power and low-latency switches, such an architecture does not provide support for a large number of hosts without increasing FIB CAM and next-hop table sizes. This poses a new challenge for switching equipment providers. Although subnet prefixes can be used as aggregation means for the double-lookup-forwarding architecture described above, this does not work in configurations in which a Virtual Local Area Network (VLAN) spans across different SDs, because at an ingress SD there is no conclusion on to which egress SD a packet should be forwarded based on subnet prefix associated with the VLAN.